Methods and systems for managing reconciliation and write-off in an accrual accounting environment

ABSTRACT

A computer-implemented method of managing reconciliation and write-off data in an accrual-based accounting environment may include steps of retrieving a plurality of transactions associated with a predetermined purchase order from a database coupled to a computer network; calculating an aggregate accrual balance of the retrieved plurality of transactions and associating the calculated aggregate accrual balance with a unique first identifier; when the aggregate accrual balance associated with the unique first identifier indicates that the predetermined purchase order is unbalanced, loading a first reconciliation table with first reconciliation information and storing the first reconciliation table in the database; enabling writing-off the aggregate accrual balance, and when the aggregate accrual balance has been written-off, removing the first reconciliation information from the first reconciliation table and storing the first reconciliation table in the database.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to the field of computer-implementedmethods and systems for managing reconciliation and write-offs in anaccrual accounting environment.

2. Description of the Prior Art and Related Information

Most companies in the business world use the accrual-based accountingmethod. When goods are purchased and received, the accrual account iscredited. When an invoice is received that is matched to a PurchaseOrder (or “PO”), the accrual account is debited for the amount invoiced.If all the receipts and invoices for purchase orders are perfectlymatched, the accrual account balance should be zero. These accrualaccounts must be reconciled and maintained to ensure that liabilitiesare properly recorded. The accrual account balance may not be zero dueto various business problems (over-receipt, over-invoice, invoice notmatched to PO, etc). Under such circumstances, the balance in theaccrual account must be written-off so that the company's financials canbe correctly stated.

Conventional processes of accrual reconciliation and write-off are laborintensive and error prone. At the outset, the user must load allaccounting lines to a table from different sub-ledgers (Receiving,Accounts Payable, Inventory, etc). For a large enterprise, the sheervolume of data that must be loaded is enormous and keeps growing. Theuser must then download these data into a spreadsheet, where they can begrouped based on the amount, PO number, and transaction date. The userconventionally must then operate inside the spreadsheet to identify theaccounting entries that need to be written-off. Each identifiedaccounting line must then be marked as written-off. The net value of thewrite-offs for every accrual account is then used to create offsetjournal entries in general ledger. This process is highly laborintensive and leads to low confidence in the accuracy of the financialstatements, and may lead to problems vis-à-vis regulatory compliance andis not well adapted to creating a reliable and accurate auditreconciliation and write-off trail. The high level of frustration inconventional reconciliation and write-off process calls for a morestreamlined, flexible, scalable, and automated accrual reconciliationand write-off process.

FIG. 1 shows a hypothetical set of business transactions to illustrateconventional accrual accounting and write-off processes. In a typicalscenario, items may be received at a shipping dock. To keep track ofthese items, a receiving inspection account may be used. The receiveditems may then be inspected at the dock, and if the items failinspection, they may be refused and sent back to the originator of theshipment. If the items pass inspection, they may be accepted and thereceiving inspection account may be debited and a selected accrualaccount credited, which creates a liability for the receiving company.In the hypothetical set of business transaction shown in FIG. 1, ten $10items have been received as shown at 102, and the aggregate valuethereof ($100) has been debited to the receiving inspection account, asshown at 104. A selected accrual account is correspondingly credited, asshown at reference numeral 106.

Concurrently or thereafter, an invoice is received for the receiveditems. For whatever reason, the received invoice is for only nine suchitems, as shown at 108. Therefore, as shown at 110, the account payableaccount must be credited for the invoiced $90 and the selected accrualaccount must be correspondingly debited for the invoiced $90, as shownat 112. It is apparent that such transactions result in the need towrite-off the balance of $10 from the accrual account (which is anaccount that is configured to store the enterprise's temporaryliabilities) as shown at 114, as the balance in the accrual account ispreferably zero. To do so, $10 is debited from the accrual account asshown at 116 and credited to an offset account (an expense account), asshown at 118. This may be done at the end of a predetermined period(e.g., at the end of the month or quarter) or at any selected time.

The accrual and write-off process described above, while barely adequatefor a few transactions, is not scalable and may become unduly burdensomeas the number of transactions increase. Such a process is also notreadily auditable, suffers from usability issues and is not readilyautomatable, as shown below relative to FIG. 2, which furtherillustrates problems associated with the conventional accrual andwrite-off processes. FIG. 2 assumes that two POs have been issued. PO#1is for a quantity of ten items at $10 each and PO#2 is also for aquantity of ten items, also at $10 each. The aggregate values of thesubject items for both PO#1 and PO#2 are to be distributed to the sameaccrual account, ACCT#1. POs may include a header, line, shipment anddistribution, with the finest granularity being at the distributionlevel.

FIG. 2 is a table showing the accrual account 202, the PO number 204,the transaction date 208, the transaction source 210, receipt number212, the invoice number 214, the quantity of items 216, the aggregateamount 218 for the quantity of items in the quantity column 216, and awrite-off flag 220. As shown in FIG. 2, the following transactionsoccurred in January 2005, the first of the two periods considered inFIG. 2. On Jan. 1, 2005, five items were received (the transactionsource 210 is “Receipt”) and were assigned a receipt number R#1 as shownin the receipt number column 212. Accordingly, $50 was credited to theaccrual account ACCT#1, as evidenced by the “−50” entry in the amountcolumn 218. In this exemplary set of transactions, on Jan. 31, 2005,invoice V#1 was received (the transaction source column 210 shows thesource of the transaction as being “Invoice”). Invoice V#1 is for fiveitems, which enables the accrual account ACCT#1 to be debited for $50,as noted by the “50” entry in the amount column 218. As thesetransactions for PO#1 are self-balancing (the received amounts arematched by the invoiced amounts), the balance of accrual account ACCT#1is zero, and the write-off flag is not asserted, as shown at 220.

As also shown in FIG. 2, during the same first period of January 2005,the first 5 of the 10 items called for by PO#2 were received on Jan. 1,2005. Accordingly, the accrual account ACCT#1 is credited with thisliability; namely $50, as evidenced by the “−50”. Thereafter, on Jan.31, 2005, invoice number V#2 is received. However, received invoicenumber V#2 is only for $40; namely for 4 items at $10 each, whereas 5items were received (see receipt number R#1 in column 212). The accrualaccount ACCT#1, therefore, may only be debited $40. Therefore, PO#2 isnot self-balancing, as the accrual account has a positive balance of $10(for PO#2, it was credited $50 on Jan. 1, 2005 but debited only $40 onJan. 31, 2005). Therefore, the write-off flag in column 220 is assertedfor PO#2, as suggested by the “Y” entry in column 220 for PO#2.

As all of the items ordered through PO#1 and PO#2 have not yet beenreceived as of Feb. 1, 2005, their respective entries are broughtforward to February and repeated. That is, rows 222 and 224 of theFebruary 2005 table, corresponding to purchase order number PO#1, arethe same as the first two rows of the table for January 2005. Likewise,rows 230 and 232 of the February 2005 table, corresponding to PO#2, arethe same as rows three and four of the January 2005 table. As shown inFIG. 2, on Feb. 1, 2005, five items ordered on PO#1 were received andassigned receipt number R#3, as shown at row 226. Accordingly, theaccrual account ACCT#1 was credited with the temporary liability of 50,as evidenced by the “−50” entry in the amount column 218. At the end ofthe month on Feb. 28, 2005, invoice V#3 for the items received on Feb.1, 2005 was received, as indicated in row 228. However, for some reason,invoice V#3 is only for 4 items; namely $40. As the accrual accountACCT#1 may only be debited for the $40 invoiced by V#3, PO#1, althoughself-balanced in the first period (January 2005), is now unbalanced inthe second period (February 2005). Therefore, the write-off flag isasserted, as shown at column 220.

Turning now to PO#2, five items were received on Feb. 1, 2005, asevidenced by receipt number R#4 at row 234. Therefore, $50 was creditedto ACCT#1 on that date. Thereafter, on Feb. 28, 2005, a new invoice V#4for PO#2 was received as shown at row 236, this time invoicing therecipient for six items, although only five were received during thatperiod. The accrual account ACCT#1 is then debited for $60, as shown inFIG. 2. This over-invoicing may have taken place deliberately tocompensate for the under-invoicing on PO#2 of V#2 on Jan. 31, 2005 orfor some other reason altogether. Alternatively, the over-invoicing ofV#4 may have been accidental. In any case, the status of the write-offflag for PO#2 is now uncertain. Indeed, for PO#2, there are now twoalternatives for writing off the January and February 2005transactions: 1) change the write-off flag for two transactions inJanuary (as PO#2 is now balanced, as the amounts credited to ACCT#1 arematched with corresponding debits) or write off both transactions againin February, as the February transactions (see rows 234, 236) are notself-balancing during that period.

As can be seen from a relatively small number of transactions, accordingto conventional methods, the entries necessary for reconciliation andwrite-off of a single accrual account rapidly grow to unmanageable size.Conventionally, even self-balancing POs show up in the table, as seen inthe case of PO#1 in January 2005, the first period considered in FIG. 2.Moreover, as can be seen, the manipulation of the write-off flag can becumbersome. Complicating an already unwieldy table, there may be manyindividual transactions covered by a single purchase order, and suchtransactions conventionally add further clutter to the reconciliationand write-off table. Moreover, the format of conventional tables is suchthat it is not readily auditable and it may be difficult to reconstructpast transactions, as there is no track record kept. From the foregoing,it may be appreciated that improved methods and systems for accrualreconciliation and write-off are needed.

SUMMARY OF THE INVENTION

According to an embodiment thereof, the present invention is acomputer-implemented method of managing reconciliation and write-offdata in an accrual-based accounting environment. Such acomputer-implemented method may include steps of retrieving a pluralityof transactions associated with a predetermined purchase order from adatabase coupled to a computer network; calculating an aggregate accrualbalance of the retrieved plurality of transactions and associating thecalculated aggregate accrual balance with a unique first identifier.When the aggregate accrual balance associated with the unique firstidentifier indicates that the predetermined purchase order isunbalanced, the method may include a step of loading a firstreconciliation table with first reconciliation information and storingthe first reconciliation table in the database. An embodiment of thepresent invention may include a step of enabling writing-off theaggregate accrual balance, and when the aggregate accrual balance hasbeen written-off, the method may include steps of removing the firstreconciliation information from the first reconciliation table andstoring the first reconciliation table in the database.

According to further embodiments, the plurality of transactions mayoriginate from sources such as Receiving, Accounts Payable and/orInventory, for example. The first reconciliation table may be areconciliation summary table and the first reconciliation informationmay include a summary of the plurality of transactions associated withthe unbalanced predetermined purchase order. When the aggregate accrualbalance associated with the unique first identifier indicates that thepredetermined purchase order is unbalanced, the method may furtherinclude a step of loading a second reconciliation table with secondreconciliation information. The second reconciliation table may be areconciliation details table and the second reconciliation informationmay include information from the plurality of transactions associatedwith the unbalance predetermined purchase order. The removing step mayalso remove the second reconciliation information from the secondreconciliation table. The loading and removing steps may be operative tomaintain only information associated with unbalanced purchase orders inthe first reconciliation table. After the aggregate accrual balance iswritten off, an embodiment of the present invention may include carryingout a step of loading a first persistent write-off table with firstwrite-off information and associating the first write-off informationwith a unique first write-off identifier. The first persistent write-offtable may be a write-off summary table and the first write-offinformation may include write-off summary information. After theaggregate accrual balance is written-off, an embodiment of the presentcomputer-implemented method may include carrying out a step of loading asecond persistent write-off table with second write-off information andassociating the second write-off information with the unique firstwrite-off identifier. The second persistent write-off table may be awrite-off details table and the second write-off information may includedetailed information from the plurality of transactions having causedthe predetermined purchase order to become unbalanced. An embodiment ofthe present invention may further include carrying out a step ofenabling reversal of the written-off aggregate accrual balance. Afterreversal of the written-off aggregate accrual balance, an embodiment ofthe present method may further include a step of re-loading the removedfirst reconciliation information into the first reconciliation table.After reversal of the written-off aggregate accrual balance, a firstpersistent write-off table may be loaded with first write-off reversalinformation and the first write-off reversal information may beassociated with a unique first write-off reversal identifier.

According to another embodiment thereof, the present invention is also amachine-readable medium having data stored thereon representingsequences of instructions which, when executed by a computing device,causes the computing device to manage reconciliation and write-off datain an accrual-based accounting environment by performing the steps ofretrieving a plurality of transactions associated with a predeterminedpurchase order from a database coupled to a computer network;calculating an aggregate accrual balance of the retrieved plurality oftransactions and associating the calculated aggregate accrual balancewith a unique first identifier. When the aggregate accrual balanceassociated with the unique first identifier indicates that thepredetermined purchase order is unbalanced, an embodiment of the presentinvention may include a step of loading a first reconciliation tablewith first reconciliation information and storing the firstreconciliation table in the database. An embodiment of the presentinvention may enable writing-off the aggregate accrual balance, and whenthe aggregate accrual balance has been written-off, steps of removingthe first reconciliation information from the first reconciliation tableand storing the first reconciliation table in the database may becarried out.

The present invention, according to a still further embodiment thereof,is a computer system for managing reconciliation and write-off data inan accrual-based accounting environment. Such a computer system mayinclude one or more processors; at least one data storage device coupledto the processor(s) and a plurality of processes spawned by theprocessor(s). According to an embodiment of the present invention, suchprocesses may include processing logic for retrieving a plurality oftransactions associated with a predetermined purchase order from adatabase coupled to a computer network; calculating an aggregate accrualbalance of the retrieved plurality of transactions and associating thecalculated aggregate accrual balance with a unique first identifier.When the aggregate accrual balance associated with the unique firstidentifier indicates that the predetermined purchase order isunbalanced, an embodiment of the present invention may include a step ofloading a first reconciliation table with first reconciliationinformation and storing the first reconciliation table in the database.An embodiment of the present invention may also enable writing-off theaggregate accrual balance, and when the aggregate accrual balance hasbeen written-off, the method may include a step of removing the firstreconciliation information from the first reconciliation table andstoring the first reconciliation table in the database.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 sets up a hypothetical set of business transactions to illustrateconventional accrual accounting and write-off processes.

FIG. 2 shows details of conventional accrual accounting and write-offprocesses over two one-month periods.

FIG. 3 shows aspects of the methods and systems for managingreconciliation and write-offs in an accrual accounting environment,according to embodiments of the present invention.

FIG. 4 shows further aspects of the methods and systems for managingreconciliation and write-offs in an accrual accounting environment,according to embodiments of the present invention.

FIG. 5 shows further aspects of the methods and systems for managingreconciliation and write-offs in an accrual accounting environment,according to embodiments of the present invention.

FIG. 6 shows still further aspects of the methods and systems formanaging reconciliation and write-offs in an accrual accountingenvironment, according to embodiments of the present invention.

FIG. 7 shows yet further aspects of the methods and systems for managingreconciliation and write-offs in an accrual accounting environment,according to embodiments of the present invention.

FIG. 8 is a flowchart illustrating an embodiment of the presentcomputer-implemented method for managing reconciliation and write-offsin an accrual accounting environment.

FIG. 9 is another flowchart illustrating further aspects of anembodiment of the present computer-implemented method methods formanaging reconciliation and write-offs in an accrual accountingenvironment.

FIG. 10 is a block diagram of a computer system with which embodimentsof the present computer-implemented methods for managing reconciliationand write-offs in an accrual accounting environment may be practiced.

DETAILED DESCRIPTION

FIG. 3 shows aspects of the methods and systems for managingreconciliation and write-offs in an accrual accounting environment,according to embodiments of the present invention. Instead of anever-growing reconciliation table, embodiments of the present inventionenvisage the generation of dynamically updating reconciliation andwrite-off tables that include only that information that is pertinent totransactions that are the subject of reconciliation and write-off. Asshown in FIG. 3, embodiments of the present invention may includegenerating, loading and dynamically managing a Reconciliation SummaryTable 300. The Reconciliation Summary Table 300, according toembodiments of the present invention, may be configured such that onlyunbalanced PO distributions are listed, such that PO distributions thatare balanced are not featured in this table. According to embodiments ofthe present invention, the aggregate accrual balance from severalsources such as, for example, Receiving, Accounts Payable and Inventorymay be associated, grouped and accessed through the use of a uniquefirst identifier—the PO distribution ID. Use of the PO Distribution IDenables the Reconciliation Summary Table 300 to remain lean, even if agreat many transactions are covered by a single PO distribution ID.Continuing with the example developed relative to FIGS. 1 and 2, onlypurchase order number PO#2 is listed in the Reconciliation Summary Table300 for the first period (January 2005), as only PO#2 is unbalancedduring that period. Consequently and according to embodiments of thepresent invention (and in contrast with the reconciliation table of FIG.2), PO#1 is not shown in table 300 because it was self-balancing duringthe period in question.

As shown in FIG. 3, such a Reconciliation Summary Table 300 may includeone or more of the following fields. Those of skill in this art,however, will readily recognize that other fields may also be includedin the table 300, in addition to or in place of the fields shown in FIG.3 and discussed hereunder. The Reconciliation Summary Table 300 may, asshown at 302 in FIG. 3, include a column to identify a specified accrualaccount. In the example developed herein, the specified accrual accountis ACCT#1. The table 300 may also include a column for the PO number, asshown at 304. The PO distribution ID may also be listed in the table300, at 306. A column to specify the received balance 308 may also beincluded, to indicate the value of the items received in the accrualaccount ACCT#1. The invoiced amount may be listed as the AccountsPayable balance, in column 310. In the example developed herein, invoiceV#2 was for only $40. Therefore, for PO#2 in the first period underconsideration, the AP Balance column 310 lists “40”, the amount invoicedon Jan. 31, 2005 (See FIG. 1). The Reconciliation Summary table 300 mayalso include a Write-Off Balance column, as shown at 312. The Write-OffBalance column 312 may be used to store the current written-off amountfor the specified PO distribution ID. In this case, the write-offbalance is zero, as PO#2, in the state in which it is shown in FIG. 2,is currently unbalanced and no amounts have been written-off as of yet.This column may be dynamically updated when and if amounts are writtenoff, as is described hereunder. The Summary Reconciliation may also, asshown in FIG. 3 at 314, include a Total Balance column. The TotalBalance column may be configured to store the aggregate accrual balancefrom many different columns and the sum of potentially many (e.g.,hundreds or thousands) transactions. According to an embodiment of thepresent invention, the aggregate accrual balance stored in the TotalBalance column 314 of table 300 may be computed by summing the valuesstored in the Received Balance column 308, the accounts Payable Balancecolumn 310 and the Write-Off Balance column 312. In the exampledeveloped herein, the aggregate accrual balance stored in the TotalBalance column 310 is “−10” as columns 308, 310 and 312 store valuesequal to −50, 40 and 0, respectively. Advantageously, the ReconciliationSummary Table 300 may include a Write-Off Checkbox column 316. It is asimple matter to write off the −10 deficiency shown in column 314 bychecking Write-Off Checkbox 316. Checking the Write-Off Checkbox 316enables the user, in a single action (such as checking a box) to writeoff amounts from multiple transactions associated with the PODistribution ID in column 306. According to another embodiment, thewriting-off process need not involve any manual input from the user.Indeed, the decision whether to write off any given amount may becodified programmatically and may enable mass write-offs based upon apredetermined tolerance or threshold amount, date, PO range or any otherrelevant factor. That is, write-off rules may be devised and coded suchas to, for example, automatically write-off amounts less than apredetermined amount (e.g., $100) on transactions that have remainedunbalanced for over three months. The tables, information and datadescribed herein may be stored in a database such as shown at 1026 inFIG. 10 and accessed over, e.g., a computer network such as, theInternet, a corporate intranet and/or a Virtual Private Network (VPN),for example.

Should the Write-Off Checkbox 316 be checked (or should the aggregateaccrual balance stored in the Total Value column 314 be written-offautomatically and programmatically) and a given PO be brought intobalance, that PO and the information related thereto may be caused todisappear (i.e., may be removed) from the Reconciliation Summary Table300 and/or Reconciliation Details Table 340 as, according to embodimentsof the present invention, only unbalanced PO distributions appeartherein. Therefore, the Reconciliation Summary and Details Tables 300,340 may be configured to dynamically update to only includetransactional information related to or associated with unbalanced PODistribution IDs. The Reconciliation Summary and Details Tables 300, 340may also be configured to dynamically remove from the tables summariesand details transactions associated with PO Distribution IDscorresponding to purchase orders that have been brought into balancethrough a reconciliation and write-off process. The ReconciliationSummary and Details Tables 300, 340 may also be configured such thatsummaries and details of purchase orders that have become unbalanced(for whatever reason) may be dynamically loaded therein.

The Reconciliation Details Table 340, according to embodiments of thepresent invention, may be configured to only include details (e.g.,transactional information) of PO Distribution IDs that are unbalanced.That is, the Reconciliation Details Table 340 may be configured tocontain only the details of those transactions associated with the PODistribution ID(s) that appear in the Reconciliation Summary Table 300.As shown in FIG. 3, only the details of unbalanced PO#2 appear in theReconciliation Details Table 340. The Reconciliation Details Table 340may, for example, include columns for the Accrual Account 318, for thePO Distribution ID 320, for the Transaction Date 322, for theTransaction Source 324 (e.g., receipt or invoice), for the ReceiptNumber 326, for the Invoice Number 328, for the Write-Off ID 330 (e.g.,a unique identifier assigned to and associated with each write-off, toenable the write-off to be reversed and to create an auditable record),for the Quantity 332 and for the Amount 334 of the transaction. Agreater or lesser number of items of information may be presented in theReconciliation Details Table 340, as those of skill in this art mayreadily recognize. Limiting the Reconciliation Tables 300, 340 to onlythose PO Distribution IDs that are unbalanced advantageously limits thenumber of transactions that appear therein and presents only thatinformation that is useful to the reconciliation and write-off processesto the user.

FIG. 4 shows aspects of the methods and systems for managingreconciliation and write-offs in an accrual accounting environment,according to further embodiments of the present invention. Specifically,FIG. 4 shows a Write-Off Summary Table 400 and a Write-Off Details Table440 according to embodiments of the present invention. As shown, theWrite-Off Summary Table 400 may include columns for all or selecteditems of information that are relevant to the write-off requested by theuser or programmatically carried out. For example, the Write-Off SummaryTable 400 may include the following columns: Write-Off ID 402 (a uniqueidentifier for each write-off), Accrual Account 404, PO Number 406, thePO Distribution ID 408, the Write-Off Date 410 (the date on which theamount was written-off), the Reversal ID 412 (a unique identifier foreach write-off reversal), the Write-Off Type 414, the Write-Off Amount416, the Write-Off Reason 418 and a Reverse Checkbox 420. As those ofskill may recognize, the Write-Off Summary table 400 may be configureddifferently than shown in FIG. 4. For example, additional, fewer ordifferent fields may be included without departing from the scope of theclaimed embodiments.

In the example developed herein, a $10 amount is being written-off (seeColumns 314 and 316 in FIG. 3) on Jan. 31, 2005, as shown in column 410.The Write-Off Type 414, in this case, is “write-off” and the write-offreason is “under invoice”, as shown by rows 336 and 338 of theReconciliation Details Table 340, in which it is shown that the accrualAccount ACCT#1 was credited with $50 because of receipt number R#2, butdebited only $40 because of the under invoicing of invoice number V#2 ofJan. 31, 2005. The Write-Off Details Table 440 may include, for example,columns for the Write-Off ID 422, the Transaction Date 424, theTransaction Source 426, the Receipt Number 428, the Invoice Number 430,the Quantity 432 and the Amount 434.

The Write-Off Details Table 440 may include any and all information thatmay be useful in preserving the sequence of events that led to the writeoff (and optionally to any reversals thereof) and creating an audittrail for write-offs. Alternately, the Write-Off Details Table maysimply provide the user with information that explains the circumstances(e.g., transactions, dates, reason codes, etc) surrounding the write-offof a particular amount. In the example developed herein, the write-offdetailed in the table 440 relates to the write-off having the Write-OffID of W#1, shown in both the Write-Off Summary and Details Tables 400,440. The table 440 shows that write-off W#1 was created because fiveitems at $10 each were received on Jan. 1, 2005 and assigned receiptnumber R#2 as shown at row 436 and that invoice V#2 for 4 items at $10each was subsequently received on Jan. 31, 2005, under-invoicing thereceived items by $10, as shown at 438. Both the Write-Off Tables 400and 440 are, according to embodiments of the present invention, dynamicin nature and are configured to automatically update as amounts arewritten off, and as (and if) write-offs are reversed.

If a write-off was made mistakenly or if a write-off later turns out notto have been necessary, embodiments of the present invention provide astreamlined mechanism for reversing a write-off. To provide suchfunctionality, a Reverse Write-Off Checkbox may be provided, such asshown at column 420 in FIGS. 4 and 5. Had, for example, the ReverseWrite-Off Checkbox 420 been checked (FIG. 4 shows the Reverse Write-OffCheckbox 420 of Write-Off ID W#1 as being unchecked), the Write-OffSummary table 500 and the Write-Off Details table 540 may be generatedand loaded as shown and described hereunder. As seen in FIG. 5, theWrite-Off Summary table 500 and the Write-Off Details table 540 mayinclude the same columns as shown and discussed relative to FIG. 4. Whena selected write-off is reversed, the aggregate accrual balancewritten-off may be credited back to the accrual account, as shown inFIG. 5. In the example developed herein, the PO#2 necessitated aWrite-Off Amount of $10. This write-off was assigned Write-Off ID W#1and the $10 amount was previously debited from the accrual accountACCT#1. Reversing this write-off causes that previously written-offaggregate accrual balance of $10 to be credited back to the ACCT#1accrual account. The reversal of the write-off may itself be assigned anew Write-Off ID (W#2 in FIG. 5) and the new write-off ID stored incolumn 402. In this case, the Write-Off Type in column 414 for W#2 maybe Write-Off Reversal, and a Write-Off reason may be inputted in column418, such as “made a mistake” or any other reason for reversing apreviously written-off amount. As a result of the reversal of thewrite-off, the Write-Off Details table 540 of FIG. 5 may show theinformation for both the original write-off W#1 (e.g., reproduce therows 436 and 438 of FIG. 4), as well as the details regarding thereversal W#2 of the write-off W#1, reinstating the amounts written-offby W#1 (e.g., Receipt R#2 of Jan. 1, 2005 and invoice V#2 of Jan. 31,2005), thereby creating an intuitive audit log of such accounting eventsover time.

Recall that the Reconciliation Summary and Details tables, according toembodiments of the present invention, may include only those purchaseorders that are unbalanced. In the example being developed herein, PO#2is once again unbalanced, due to the reversal (W#2) of the $10written-off by W#1. Therefore, as the present Reconciliation Summary andDetails tables are dynamic in nature, PO#2 may again be represented inboth the Reconciliation Summary and Details tables 600, 640, as shown inFIG. 6. In this example, reversal of the $10 initially written-off byW#1 reinstates (e.g., re-loads) PO#2 to the Reconciliation Summary table600, which is now identical to that shown in FIG. 3. As tables areupdated, they may be stored in the database 1026. As table 600 is asummary table, it is unnecessary to show any write-off or write-offreversal information therein. All that need be represented in theReconciliation Summary table 600 is that PO#2 is unbalanced, and why (inthis case, a received balance of 50 was credited to the ACCT#1 accrualaccount, but only 40 was debited therefrom), although the table may beconfigured to store and/or display more or less information than shown,as those of skill may recognize.

The Reconciliation Details table 640, according to embodiments of thepresent invention may include all of the information to accuratelymemorialize the sequence transactions that led to the initial state ofimbalance of D#2 (R#2 crediting $50 to ACCT#1, V#2 only debiting $40from ACCT#1 as shown in rows 336, 338), the writing-off of the $10amount with Write-Off ID W#1 (as seen in row 602), and the subsequentreversal of the write-off with the unique write-off identifier Write-OffID W#2 (as shown at row 604).

FIG. 7 shows Reconciliation Summary table 700 and the ReconciliationDetails table 740 for the second period of February 2005, to illustratefurther aspects of the dynamic reconciliation and write-off methodsaccording to embodiments of the present invention. In the exampledeveloped herein, new transactions were recorded in February 2005against PO#2, which brought PO#2 into balance. Such new transactions mayhave included, for example, receipt of the second five items (whichwould have caused the accrual account ACCT#1 to be credited with 50) andreceipt of an over-invoice for 6 items ($60), which would have reducedthe value of aggregate accrual balance stored in the Total Balance 314for PO#2 down to zero, thereby bringing PO#2 into balance (an unbalancedpurchase order may be characterized as having an aggregate accrualbalance that is non-zero). However, as PO#2 was brought into balance inFebruary 2005 in the illustrative example developed herein, PO#2 nolonger shows up in the Reconciliation Summary table 700 or theReconciliation Details table 740, as these tables are preferablyconfigured to show only unbalanced purchase orders.

As shown in FIG. 7, however, new transactions associated with PODistribution ID D#1 were recorded against PO#1 which made the(previously balanced) PO#1 unbalanced. Therefore, a summary of thetransactions recorded against PO#1 during the second period may be shownin the Reconciliation Summary table 700 and the details of thetransactions associated with PO Distribution ID may be stored and shownin the Reconciliation Details table 740. As shown in table 700, thevalue ($90) stored in the Accounts Payable column 310 is insufficient tobalance out the amount (−$100) currently credited to the accrual accountACCT#1, as shown in the Receive Balance column 308. The transactionsthat gave rise to this imbalance in PO#1 are shown in the ReconciliationDetails table 740. Rows 702 and 704 are reproduced from rows 238 and240, respectively, shown in FIG. 2. These transactions dynamicallyappear in (i.e., were re-loaded into) the Reconciliation Details table740 because PO#1 has been made unbalanced by the later-occurringtransactions of Feb. 1, 2005 and Feb. 28, 2005. Indeed, on Feb. 1, 2005,five additional items were received and this receipt was assignedReceipt Number R#3. Receipt Number R#3 caused the accrual account ACCT#1to be credited with $50, as shown at row 706. However, on Feb. 28, 2005,Invoice Number V#3 was received for $40, under-invoicing the five itemsreceived on Feb. 1, 2005 by $10. Therefore, the accrual account ACCT#1was debited only $40, which caused the aggregate accrual balance of −$10to be stored in the Total Balance column 314.

According to embodiments of the present invention, the data in theWrite-Off Summary and Write-Off Details tables is preferably persistent,for at least legal and auditing purposes. With respect to the exampledeveloped in the figures, at the end of the second period of February2005, PO#1 is unbalanced and thus the summary of this imbalance and thetransactions that gave rise to the imbalance appear in theReconciliation tables. PO#2 is balanced and thus does not appear in theReconciliation tables. However, the write-off transaction (W#1) and thewrite-off reversal (W#2) that have been performed for PO#2 arepersistent in the Write-off tables, as shown in FIG. 5. The $10 amountshown in column 314 in FIG. 7 for PO#1 may be written-off at any time,such as the end of the second period or at some later time. It isunlikely that future transactions will bring PO#1 into balance, as all10 items called for by PO#1 have been received. However, a later invoice(say V#4) may be received at some later date that would zero out the $10balance in ACCT#1. It is to be noted that, over time and for most normalbusinesses, most purchase orders should be self-balanced and write-offshould be necessary for only a small number of the issued purchaseorders. That the Reconciliation and thus the Write-Off tables onlyinclude data regarding unbalanced purchase orders and fact that mostpurchase orders are self-balanced combine to maintain the Reconciliationtables lean and the Write-Off tables at a manageable size.

FIGS. 8 and 9 are flowcharts that illustrate aspects of the presentstreamlined accrual reconciliation and write-off process, according toembodiments of the present invention. As shown therein, step S81 callsfor a determination as to whether items were received on a predeterminedpurchase order. If so, a selected accrual account may be credited forthe value of the received items (which value is usually specified in thepredetermined purchase order), as shown at S82. A unique firstidentifier (such as the PO Distribution ID discussed herein above, forexample) may be associated with any transactions against thepredetermined purchase order from, e.g., Receiving, Accounts Payable orInventory. If no items were received in step S81, the method may proceedto step S83, in which it may be determined whether an invoice has beenreceived (or retrieved from database 1026) against the predeterminedpurchase order. If so, the selected accrual account is correspondinglydebited and that transaction associated with the unique identifier, asshown at S84. If no invoice is received in step S83, it may bedetermined whether the predetermined purchase order is unbalanced—thatis, whether the aggregate accrual balance is non-zero. If thepredetermined purchase order is indeed unbalanced as determined at stepS85, step S86 may be carried out. Therein, a summary of the informationgiving rise to the imbalance may be loaded in a first reconciliationtable (such as a Reconciliation Summary table, for example) and/ordetails of the transactions that gave rise to the unbalanced purchaseorder may be loaded into a second reconciliation table (such as aReconciliation Details table, for example). Thereafter, at step S89, itmay be determined whether the user wishes to write-off the aggregateaccrual balance. If the user wishes to write-off the aggregate accrualbalance, the steps outlined in FIG. 9 may be carried out, as describedin detail hereunder. If the user does not wish to write-off theaggregate accrual balance at step S89 or does not wish to do so at thistime, the method may revert back to step S81.

If it is determined in step S85 that that predetermined purchase orderis not unbalanced, step S87 may be carried out. As shown in FIG. 8, stepS87 calls for determining whether the (first and second or Summary andDetails, respectively) reconciliation tables contain previously loadedinformation of the predetermined purchase order. This may occur, forexample, if the non-zero aggregate accrual balance of a previouslyunbalanced purchase order was written-off but the tables not yetupdated. If the reconciliation tables indeed contain previously loadedinformation of the predetermined purchase order (indicating that thepurchase order was previously unbalanced), step S88 may be carried out,in which information associated with the now balanced predeterminedpurchase order may be removed from the first reconciliation table (e.g.,Reconciliation Summary table) and from the second reconciliation table(e.g., Reconciliation Details table). Thereafter, the method may revertto step S81. This removal of information from the reconciliation tablesmay be carried out dynamically and without any user intervention, as thereconciliation tables are configured, according to embodiments of thepresent invention, to contain only information associated withunbalanced purchase orders. If step S87 determines that thereconciliation tables have not previously been loaded with informationassociated with a previously unbalanced purchase order, the method mayrevert to step S81.

If in step S89 it is determined that the aggregate accrual balance is tobe written-off, the steps of FIG. 9 may be carried out. As showntherein, if a non-zero aggregate accrual balance is to be written off,step S91 may be carried out, in which a first persistent write-off table(such as a Write-Off Summary tables 400, 500, for example) may be loadedwith persistent first write-off information and the persistent firstwrite-off information may be associated with a unique first write-offidentifier (such as W#1 in FIG. 5). Thereafter, as shown at S92, stepsmay be carried out to load a second persistent write-off table (such asWrite-Off Details tables 440, 540 for example) with persistent secondwrite-off information and to associate the second write-off informationwith the unique first write-off identifier. The second write-offinformation may include detailed information from the plurality oftransactions associated with the unbalanced predetermined purchaseorder. Because the first and second reconciliation tables loaded in stepS86 are dynamic and configured to contain only information associatedwith unbalanced purchase orders, the information having given rise tothe written-off aggregate accrual balance may then be removed from thefirst and second reconciliation tables, as called for by step S93.

After a write-off has been carried out, embodiments of the presentinvention enable the user to reverse the write-off. For example, theuser may have made a mistake in writing-off the aggregate accrualbalance. Alternatively, a new transaction on the predetermined purchaseorder may have occurred, which later-occurring new transaction may havebalanced the predetermined purchase order had the aggregate accrualbalance not been previously written off. For whatever reason, ifreversal of a previously carried out write-off is desired in step S94, anew entry may be generated in the first persistent write-off tableindicating the reversal of the write-off and a new write-off identifiermay be associated and stored therewith (as shown at W#2 in FIG. 5), ascalled for by step S95 and as shown for example, in table 500. Thetransactions having given rise to the previously removed firstreconciliation information (in step S88) may then be reinstated (i.e.,re-loaded) back into the first reconciliation table (e.g., any one orboth of the Reconciliation Summary and Reconciliation Details tables) asshown at S96, as reversal of the write-off changed the predeterminedpurchase order from a balanced state to an unbalanced state, therebynecessitating that the Reconciliation tables be dynamically updated.Thereafter, the method may revert back to step S86 in FIG. 8.

Embodiments of the present invention may include computer programs anduser interfaces (such as forms and reports) that generate and manage theReconciliation and Write-Off tables described above and that make theaccrual reconciliation and write-off process more efficient andscalable. A form may be provided to enable the user to select whichaccrual accounts (in the example developed herein, the accrual accountis ACCT#1) to be considered in the accrual reconciliation process. Anaccrual load program may be scheduled to run incrementally with a daterange. The data load process carried out by the accrual load program maybe re-runnable and dynamic in that only unbalanced PO distributions willhave data in the Reconciliation tables and those data may include allhistorical transactions for that PO distribution ID. This mechanismleads to a lean table and makes the process scalable. After the accrualdata is loaded, customizable reports (in summary or detail mode andexportable to, e.g., Microsoft Excel) may be generated to assist in theanalysis of the contents thereof and in performing the reconciliation.Filters and the ability to group the data by the outstanding balance,accrual account, PO's aging period days and the like may be provided.Based on such reports, the user may decide to write-off an aggregateaccrual balance. Alternatively, such write-off may be carried outprogrammatically, without any user intervention. For example, rules maybe configured to write off aggregate accrual balances that satisfysimple or complex criteria. Since the accounting entries (from whateversource, such as from Receiving, Accounts Payable or Inventory, forexample) are grouped together based on a unique first identifier (shownin the figures as the PO Distribution ID), instead of marking eachaccounting entry as write-off, embodiments of the present invention maycalculate the aggregate accrual balance for each PO distribution ID andcreate a write-off transaction that will offset this aggregate accrualbalance. Once this write-off transaction is generated, the POdistribution is balanced and all its associated accounting lines may beremoved from the Reconciliation Summary and Details tables. Unlikeconventional manual processes, the offset journal entries from thewrite-off transaction are created automatically and may be assigned aunique write-off identifier, as shown at W#1 in tables 500 and 540 inFIG. 5. The ability to write-off the aggregate accrual balance and theunique write-off identifier make the process efficient, and make masswrite-offs possible for large enterprises. For example, the user maydefine rules to write-off all PO distributions with a low outstandingaggregate accrual balance (say less than $100, for example) in one shot.

According to further embodiments of the present invention, a user mayreverse a write-off. The write-off reversal is interrelated with theloading of the Reconciliation Summary and Details tables, in that allhistorical transactions associated with the unique first identifier(e.g., the PO Distribution ID) may be loaded back into theReconciliation Details table and reflected in the Reconciliation Summarytable. Similar to the write-off process, journal entries for write-offreversal may also be created automatically and identified by a uniquewrite-off reversal identifier, as shown at W#2 in table 640 of FIG. 6.

FIG. 10 illustrates a block diagram of a computer system 1000 upon whichembodiments of the present inventions may be implemented. Computersystem 1000 includes a bus 1001 or other communication mechanism forcommunicating information, and one or more processors 1002 coupled withbus 1001 for processing information. Computer system 1000 furthercomprises a random access memory (RAM) or other dynamic storage device1004 (referred to as main memory), coupled to bus 1001 for storinginformation and instructions to be executed by processor(s) 1002. Mainmemory 1004 also may be used for storing temporary variables or otherintermediate information during execution of instructions by processor1002. Computer system 1000 also includes a read only memory (ROM) and/orother static storage device 1006 coupled to bus 1001 for storing staticinformation and instructions for processor 1002. A data storage device1007, such as a magnetic disk or optical disk, may be coupled to bus1001 for storing information and instructions. The computer system 1000may also be coupled via the bus 1001 to a display device 1021 fordisplaying information to a computer user. An alphanumeric input device1022, including alphanumeric and other keys, may be coupled to bus 1001for communicating information and command selections to processor(s)1002. Another type of user input device is cursor control 1023, such asa mouse, a trackball, or cursor direction keys for communicatingdirection information and command selections to processor 1002 and forcontrolling cursor movement on display 1021. The computer system 1000may be coupled, via a network 1024, to a database 1026 configured tostore the present reconciliation and write-off data and otherinformation.

Embodiments of the present invention are related to the use of computersystem and/or to a plurality of such computer systems to enable methodsand systems for managing reconciliation and write-off data in anaccrual-based accounting environment. According to one embodiment, themethods and systems described herein may be provided by one or morecomputer systems 1000 in response to processor(s) 1002 executingsequences of instructions contained in memory 1004. Such instructionsmay be read into memory 1004 from another computer-readable medium, suchas data storage device 1007. Execution of the sequences of instructionscontained in memory 1004 causes processor(s) 1002 to perform the stepsand have the functionality described herein. In alternative embodiments,hard-wired circuitry may be used in place of or in combination withsoftware instructions to implement the present invention. Thus, thepresent invention is not limited to any specific combination of hardwarecircuitry and software. Indeed, it should be understood by those skilledin the art that any suitable computer system may implement thefunctionality described herein. The computer system may include one or aplurality of microprocessors working to perform the desired functions.In one embodiment, the instructions executed by the microprocessor ormicroprocessors are operable to cause the microprocessor(s) to performthe steps described herein. The instructions may be stored in anycomputer-readable medium. In one embodiment, they may be stored on anon-volatile semiconductor memory external to the microprocessor, orintegrated with the microprocessor. In another embodiment, theinstructions may be stored on a disk and read into a volatilesemiconductor memory before execution by the microprocessor.

While the foregoing detailed description has described preferredembodiments of the present invention, it is to be understood that theabove description is illustrative only and not limiting of the disclosedinvention. Those of skill in this art will recognize other alternativeembodiments and all such embodiments are deemed to fall within the scopeof the present invention. Thus, the present invention should be limitedonly by the claims as set forth below.

1. A computer-implemented method of managing reconciliation andwrite-off data in an accrual-based accounting environment, the methodcomprising: retrieving, at one or more computer systems, a plurality oftransactions associated with a predetermined purchase order from adatabase in communication with the one or more computer systems;calculating, with one or more processors associated with the one or morecomputer systems, an aggregate accrual balance of the retrievedplurality of transactions; storing, in the database associated with theone or more computer systems, the calculated aggregate accrual balancein association with a unique first reconciliation identifier;determining, with the one or more processors associated with the one ormore computer systems, whether the aggregate accrual balance associatedwith the unique first reconciliation identifier indicates that thepredetermined purchase order is unbalanced; populating, with the one ormore processors associated with the one or more computer systems, afirst reconciliation table in the database associated with the one ormore computer systems with first reconciliation information when theaggregate accrual balance associated with the unique firstreconciliation identifier indicates that the predetermined purchaseorder is unbalanced; generating, with the one or more processorsassociated with the one or more computer systems, information configuredfor displaying the first reconciliation information from the firstreconciliation table together with first functionality enablingwriting-off the aggregate accrual balance associated with the uniquefirst reconciliation identifier; determining, with the one or moreprocessors associated with the one or more computer systems, whether thefirst functionality indicates that the aggregate accrual balanceassociated with the unique identifier has been written-off; and updatingthe first reconciliation table in the database associated with the oneor more computer systems in response to removing the firstreconciliation information from the first reconciliation table when thefirst functionality indicates that the aggregate accrual balanceassociated with the unique first reconciliation identifier has beenwritten-off.
 2. A non-transitory machine-readable medium having datastored thereon representing sequences of instructions which, whenexecuted by a computing device, causes the computing device to managereconciliation and write-off data in an accrual-based accountingenvironment, the machine-readable medium comprising: code for retrievinga plurality of transactions associated with a predetermined purchaseorder from a database; code for calculating an aggregate accrual balanceof the retrieved plurality of transactions; code for storing thecalculated aggregate accrual balance in the database in association witha unique first reconciliation identifier; code for determining whetherthe aggregate accrual balance associated with the unique firstreconciliation identifier indicates that the predetermined purchaseorder is unbalanced; code for populating a first reconciliation table inthe database with first reconciliation information when the aggregateaccrual balance associated with the unique first reconciliationidentifier indicates that the predetermined purchase order isunbalanced; code for generating information configured for displayingthe first reconciliation information from the first reconciliation tabletogether with first functionality enabling writing-off the aggregateaccrual balance; code for determining whether the first functionalityindicates that the aggregate accrual balance has been written-off; andcode for updating the first reconciliation table in the database inresponse to removing the first reconciliation information from the firstreconciliation table when the first functionality indicates that theaggregate accrual balance associated with the unique firstreconciliation identifier has been written-off.
 3. The non-transitorymachine-readable medium of claim 2, wherein the plurality oftransactions originate from at least some of Receiving, Accounts Payableand Inventory.
 4. The non-transitory machine-readable medium of claim 2,wherein the code for populating the first reconciliation table comprisescode for generating a reconciliation summary table in the database andwherein the first reconciliation information includes a summary of theplurality of transactions associated with the unbalanced predeterminedpurchase order.
 5. The non-transitory machine-readable medium of claim2, further comprising code for populating a second reconciliation tablein the database with second reconciliation information.
 6. Thenon-transitory machine-readable medium of claim 5, wherein the code forpopulating the second reconciliation table comprises code for generatinga reconciliation details table and wherein the second reconciliationinformation includes detailed information from the plurality oftransactions associated with the unbalance predetermined purchase order.7. The non-transitory machine-readable medium of claim 6, wherein thecode for updating the first reconciliation table in the database inresponse to removing the first reconciliation information from the firstreconciliation table when the first functionality indicates that theaggregate accrual balance associated with the unique firstreconciliation identifier has been written-off further comprises codefor updating the second reconciliation table in the database response toremoving the second reconciliation information from the secondreconciliation table.
 8. The non-transitory machine-readable medium ofclaim 2, wherein only information associated with unbalanced purchaseorders is maintained in the first reconciliation table.
 9. Thenon-transitory machine-readable medium of claim 2, further comprising:code for populating a first persistent write-off table in the databasewith first write-off information; and code for storing the firstwrite-off information in the database in association with a unique firstwrite-off identifier.
 10. The non-transitory machine-readable medium ofclaim 9, wherein the code for populating the first persistent write-offtable comprises code for generating a write-off summary table andwherein the first write-off information includes write-off summaryinformation.
 11. The non-transitory machine-readable medium of claim 9,further comprising: code for populating a second persistent write-offtable in the database with second write-off information; and code forstoring the second write-off information in the database in associationwith the unique first write-off identifier.
 12. The non-transitorymachine-readable medium of claim 11, wherein the code for populating thesecond persistent write-off table comprises code for generating awrite-off details table and wherein the second write-off informationincludes detailed information from the plurality of transactions havingcaused the predetermined purchase order to become unbalanced.
 13. Thenon-transitory machine-readable medium of claim 2, further comprisingcode for generating information configured for displaying the firstreconciliation information from the first reconciliation table togetherwith second functionality enabling reversal of the written-off aggregateaccrual balance.
 14. The non-transitory machine-readable medium of claim13, further comprising code for re-populating the removed firstreconciliation information into the first reconciliation table in thedatabase when the second functionality indicates reversal of thewritten-off aggregate accrual balance.
 15. The non-transitorymachine-readable medium of claim 13, further comprising: code forpopulating a first persistent write-off table in the database with firstwrite-off reversal information; and code for storing the first write-offreversal information in the database in association with a unique firstwrite-off reversal identifier.
 16. The non-transitory machine-readablemedium of claim 2, further comprising code for generating customizablereport of the first reconciliation information.
 17. The non-transitorymachine-readable medium of claim 16, wherein the customizable report isin summary or detail mode.
 18. A computer system for managingreconciliation and write-off data in an accrual-based accountingenvironment, the computer system comprising: at least one processor; andat least one data storage device coupled to the at least one processorand configured to store a plurality of processor-executable instructionsincluding processing logic for: retrieving a plurality of transactionsassociated with a predetermined purchase order from a database;calculating an aggregate accrual balance of the retrieved plurality oftransactions; storing the calculated aggregate accrual balance in thedatabase in association with a unique first reconciliation identifier;determining whether the aggregate accrual balance associated with theunique first reconciliation identifier indicates that the predeterminedpurchase order is unbalanced populating a first reconciliation table inthe database with first reconciliation information when the aggregateaccrual balance associated with the unique first reconciliationidentifier indicates that the predetermined purchase order isunbalanced; generating information configured for displaying the firstreconciliation information from the first reconciliation table togetherwith first functionality enabling writing-off the aggregate accrualbalance; determining whether the first functionality indicates that theaggregate accrual balance has been written-off; and updating the firstreconciliation table in the database in response to removing the firstreconciliation information from the first reconciliation table when thefirst functionality indicates that the aggregate accrual balanceassociated with the unique first reconciliation identifier has beenwritten-off.